Subject: Getting EBN XID parms from temporary link station control block

From: Roy Brabson <[email-masked]>
Date: 9 Aug 96 12:10:15

> The ATM architecture suggests that when a node receives a call, it use
> assumed XID and link station parameters, until XID(np) when it learns the
> TG number.  An implementation might well create a "temporary" LSCB
> containing these assumed values, until it knows enough to reference the
> real LSCB, containing defined values specific to that TG number, ATM
> address, or partner CP.  (A node placing a call knows what parameters to
> use because it can look in the control block for the ATM address it is
> calling.)

It would be more helpful to understood exactly which values a node will
not know when it sends XID(np) - that is, which values may differ in an
XID(np) sent by one node from the values sent by another node on XID(np).
In order to send the correct values on XID(np), the correct link station
definition must be located.  I guess what I'm trying to determine the
latest point at which the link station definition for the ATM link can be
found - before sending XID(np), or upon receipt of XID(np) from the
partner node but after sending your own XID(np).

I know that VTAM will select the PU (equivalent to the link station in
this context) when XID(pn) is received from the adjacent node.  The
values for ISTG, etc., can then be retrieved and the correct indicator
values included on XID(np).  I'm just trying to determine if this is
simply an "implementation problem" or an "architecture problem".

> EBN architecture has assumed that a node always knows how to set the ISTG
> indicator on XID, based on its local definition for partner's subnetwork
> affiliation (native/nonnative/negotiable).  Subnet affiliation is
> currently defined on a port or link station basis, although it is
> actually enforced on an adjacent-CPnane basis.

Actually, EBN (at least VTAMs) can define subnetwork affiliation on
a CP, port, or link station basis.  However, you are correct that any
two TGs between the same two nodes must share the same subnetwork
affiliation.

> PROBLEM CASE
> ____________
>
> Assume that an EBN has an ATM port over which many SVCs can be activated.
> These SVCs may include TGs to native and non-native nodes.  Assume also
> that two EBNs have the same NETID.  One EBN defines the link as native
> and the other calls it negotiable.
>
> A call comes in and the first flow the EBN receives is an XID(null).  No
> CP name is present, and, in the worst case, the caller's ATM address is
> absent.  The EBN must decide what value to put in the ISTG indicator on
> XID(pn).

If the EBN is unsure of the ISTG value to place in XID(pn), then the EBN
should *not* set the ISTG until XID(np).  There are plenty of cases
where the EBN will know that this link may/may not be an ISTG during
XID(pn) and can set the indicator.  But remember, an EBN can turn the
ISTG indicator on at any time, but it may not turn it back off once it
has been set.  The rule should be "when in doubt, don't set the ISTG
indicator".

> EBN actually enforces subnet affiliation on a partner-CPname basis.  This
> is because all parallel TGs to a given partner are checked for being the
> same type (both ISTG, both non-ISTG).
>
> EBN architecture already lets the EBN change its node type (EN/NN) and
> flip the ISTG indicator from 0 to 1 between XID(pn) and (np) -- but not
> from 1 to 0.  The EBN treats both these indicators as valid during
> XID(pn).

While the EBN treats the ISTG indicator as valid during XID(pn), this
is only true if the ISTG indicator is set.  That is, a node might not
set the ISTG indicator during XID(pn) but later set the ISTG indicator
during XID(np).

> 2.  EBN-03:
>
>     a.  Define adjacent subnet affiliation on Define_Adjacent_CP instead
>         of Define_Port or Define_LS.

I believe we should continue to allow subnetwork affiliation to be
defined on the port and/or link station, in addition to being defined
on a CP basis.  Think about a slow speed switched link.  If subnetwork
affiliation is only allowed on a CP basis, then *every* CP which may
wish to connect over the switched link must be pre-defined at the EBN
as being non-native.  For large corporations or service providers, this
can amount to a massive amount of system definition, whereas placing
the definition on a port or link station uses only a single definition.

>     b.  If the adjacent CP's subnet affiliation is defined as negotiable,
>         then once the EBN determines the adjacent CP's subnet affiliation
>         (after first link activation and negotiation), all subsequent
>         parallel TGs to the same CP, active at the same time, must have
>         matching subnet affiliation value.  In other words subnet
>         affiliation is enforced on a CP name basis, whether it is defined
>         or negotiated.

This has always been the case.  In fact, it even goes further.  Any
given node must maintain the same subnetwork affiliation to *all*
adjacent nodes which reside in the same subnetwork.  That is, if I am
non-native to any node in a given subnetwork, then I must be non-native
to *all* nodes in that subnetwork.  The same is true of native.

Roy Brabson

---

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 9 Aug 1996 10:09:00 -0400

In message "Getting EBN XID parms from temporary link station control block", 
you write:

>An issue exists when a node supporting HPR/ATM is also an EBN.  This note
>describes the problem and a proposed fix.  (Printing is recommended!)
>
Could you explain why this has anything specific to do with HPR/ATM?  The
fact that your proposed solution consists of a clarification in the base HPR
specification plus some additional text in the EBN specification suggests
that ATM is a red herring.

Furthermore I understood that the EBN specification does not support HPR.
Therefore it does not support HPR/ATM.  In that case an EBN could only
communicate through an ATM port if it had support for the LLC2/ATM stack.  We
have not yet specified the architecture for an ATM node which supports both
the LLC2 and the native HPR protocol stacks.  That is something which I am
supposed to make a proposal on.
>BACKGROUND
>__________

This was not a problem in the base architecture for LANs because the node
uses the remote MAC address to locate the target LSCB.  I personally consider
the base architecture to be excessively restrictive in this part of the
specification.  Firstly it demands a lot of preconfiguration, one of the
characteristics of APPN which is most criticized.  Secondly it it not
suitable for larger nodes which have multiple LAN attachments, and therefore
would not want to enforce that specific link stations must be attached 
through specific ports.  Furthermore it is annoying that changing a station's
method of attachment, which therefore would affect its MAC address, or even
if it had one, should require a change of definitions in its neighbours.

Temporary LSCBs already exist in the base architecture for dial lines.  I 
believe that the concern raised here applies to dial lines as well.  It might
seem strange to define an EBN on a conventional dial line, however,
particularly if you include X.25 SVCs as dial lines, it is not that unusual
for networks to be casually connected in this way.

>PROPOSED FIX
>This problem can be solved by having the right defaults in the temporary
>link station control block.
>
>This design is similar in concept to how EBN decides what node type
>appearance to present.  The EBN and PBN indicators are valid during
>XID(pn).  An EBN decides what node type to present in XID(np) based on
>its partner's node type in XID(pn).  An EBN may change its node type
>between XID(pn) and (np).
>
>
>PROPOSED DOCUMENTATION OF FIX
>______________________________
>
>
>1.  HPR-06:
>    Add defaults for temporary LSCB.  ISTG default = native.
>    Other defaults - to be specified.

The HPR specification does not discuss ISTGs because the EBN specification
was not part of the public documentation at the time.  The current EBN
specification does not support HPR, so it is unclear why the HPR
specification should discuss EBN.

>    c.  Add FSM or XID flows showing XID(pn) and (np) processing when
>        using a temporary LSCB.
>
>    d.  Enumerate all the parameters affected by the use of a temporary
>        LSCB.

EBN is also applicable to conventional switched links, including X.25 SVCs
using QLLC and frame-relay SVCs using BNN, which therefore also use temporary
LSCBs.

Jim Cobban   |  [email-masked]                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Nortel.                                         |